[UPDATE]: A reader from planet debian (thank you Ross!) just made me noticed that this was definitely not useful. On the (standard) intel documentation page, there's some icons on the top right, like stuff for social networks (facebook, linkedin, twitter and some other), a print icon and a down arrow which I didn't notice at all but which is a direct download link to the PDF. Sorry Intel for doubting you! Starting recently, Intel has started to provide documentation using a flash pdf viewer (example here). This is really painful. I personnaly don't use flash (the flash player is not installed on most of my boxes), I have concerns over flash security wise and I don't like the fact it's proprietary, that the x86_64 version lags behind etc. On top of that, just *using* the flash pdf viewer is painful. It's slow, you're restricted to your browser, search is inexistent, you can't save them for reading them offline. Trying to dig a little inside the Intel website, I had a thought. Who in the world can't use flash? Linux people, yes (at least some of them) but nobody cares. But iPhone/iPad users don't have flash player on their OS, meaning they can't read Intel docs. Or can they? Thanks to the Inspect element tool in webkit browsers, one can easily watch the above website and see something interesting. The div containing the flash applet is style like:

<div id="viewerPlaceHolder" class="nonipad">

Since the last post, few things did happen. Basically, it's still not the right time for Debian users to upgrade to Xfce 4.8. We eventually managed to upload the whole desktop part (except the xfce metapackage) to experimental and we did upload some of the goodies too. Licensing issues have been solved so the concerned packages have been uploaded, and we're right now waiting on the three packages sitting in NEW.

• garcon is really mandatory for Xfce 4.8 since it implements the menu library, used by xfce4-panel, xfdesktop and xfce4-appfinder;
• thunar-vfs is needed if you want to keep the goodies not yet ported to the new thunar gio-based API (right now that means squeeze, the archiver, not the distribution);
• tumbler is a replacement for thunar-thumbnailers, implementing a standard thumbnailing interface, so it's possible to skip it for now.

So you'll need to be a little more patient and kindly wait for our ftp-masters to process the (quite huge) NEW backlog. After that we'll need a bit more time in experimental to test upgrade cases, then we'll do an upload to unstable of the whole desktop part and the whole goodies. Upgrading to xfce4-panel 4.8 means *all* plugins need to be rebuilt too, so that means a huge upgrade and a quite large transition to handle for the release team, so we'll have to schedule the unstable upload with them in order not to break all their plans (yes, we try to be good Debian citizens) So please be patient, but you'll see Xfce 4.8 in unstable in a not too distant future. I'll put an update here when we'll need brave volunteers willing to break their systems by doing upgrade tests. [UPDATE]: garcon, thunar-vfs and tumbler were just accepted into experimental, thanks to our ftp-masters. Now we'll synchronize with release team and upload to unstable when possible.

Now that Squeeze has been released, we (the pkg-xfce group) are in the process of uploading 4.8 to Debian. And we are uploading it to experimental for good reasons. Not that 4.8 is broken, but the packages are, and we're aware of it. Some packages are still in NEW, some are not uploaded because of some licensing issues, some have not been uploaded because we didn't yet have the time. What does this mean for you? That you should *not* upgrade to Xfce 4.8. Not all packages will be upgraded, and mixing 4.6 and 4.8 is a bad idea. We don't know yet what will happen (and that's the whole point of uploading to experimental), and it seems that there are issues indeed. So unless you're willing to fix the problems, don't upgrade to 4.8. It's not complete and it *will* break your install. I wouldn't recommend building and installing from our svn repository (for the sames reasons) nor from another (since upgrade path won't be guaranteed and we won't be able to fix them for you). So please be patient, we will upload 4.8 to unstable at one point, and there will still be polishing to be made if you want to help.

These days, I've been used to a very specific $EDITOR usage. I use my (Xfce) workspaces as context switch. Basically, each time I need to start a new activity I open a new workspace, open some terminals, maybe a browser, an editor (gvim) window etc. Then when I'm done, I delete that workspace. I can have multiple activities at once, and switch from one to another depending on various stuff. On those workspaces, I'd like to be able to have only one editor window, even when I open new files using gvim foo.c . But I'd like to have one editor window per workspace, not one global editor, since I'd like the editor to be context-specific too. I recently heard about the gvim remote stuff, and I've came with the following gvim function (zsh syntax):

function gvim()
desktop=$(xprop -root -notype -f _NET_CURRENT_DESKTOP 0c '$0+\n' _NET_CURRENT_DESKTOP)
if [ "$#" -ge "1" ];
then
gvimargs="--remote-tab-silent"
fi
=gvim --servername $desktop $gvimargs $*
The xprop trick is a hackish way to stick one gvim window per workspace, it might need to be adjusted if one has a two monitors setup and want to be able to have one editor per monitor per workspace. Basically, that snippet checks if a gvim server already exists with the current workspace name. If yes, it opens the file(s) in it, if not it run a new gvim server and opens the file there. It works more or less fine, but it has one problem: it fails badly when one needs to give args to the gvim call. Those args are usually placed *before* filenames, so in my case it won't work. One way to fix this would be to loop on all the args, check if the arg is an existing file, in case add it to $files. If not, add it to $args, then call gvim with the correct order. Works, except when you want to edit a new file, where you're back to point one. All in all, it'd work, but it's not really a nice way to do it, imho. So I'm calling for help, in case anyone has an idea about that. Basically, is there a way to say to gvim always open files in a remote server, run it if it's not already running using the config file and not an argument (so I don't mess with the command line). I do need the servername to be desktop specific though, so it's still a difficulty. NOTE: I know that emacs has some kind of remote server habilities too, but I'm not sure how it works and if it'd be possible to do that in emacs, and I'm not really an emacs user and don't really intend to switch. If you have any idea, feel free to comment (by mail), I might do a later post when I have an enhanced solution.

Since people seem to like it, I ll be trying to publish some news about ongoing work on the XSF side, on a (possibly) regular basis. Let s have a look at what happened since last time I blogged about X in Debian, mostly by checking what appeared in my =debian-x mailbox. Debian XSF News #1

• mesa 7.9 was uploaded to experimental by Julien Cristau.
• Jurij Smakov uploaded a bunch of xserver-xorg-sun* drivers to experimental for us.
• I started a debian/xsf-tools.git repository to gather some tools for people wishing to work on X-related packages. For now it contains the usual tagging script, an mrconfig file to ease downloading/updating all XSF packages, thanks to the mr tool, and some bits of documentation. I also added the git URL to the upstream repositories to debian/watch* for all packages.
• Christopher James Halse Rogers started a discussion about the Ubuntu plans for Natty release. This is mostly about DRI, and unfortunately, I haven t digged into mesa yet, but thankfully we had some answers from upstream there.
• I uploaded many xfonts-* packages, prepared by Julien Cristau.
• I uploaded many x11-* bundles as well. Why are we creating bundles? Because there are many tiny applications, which (from the distribution point of view) don t deserve their own package. For example x11-apps contains toys like xclock, xeyes, or xlogo.
• I uploaded many lib* packages, plus pixman. When there were no fundamental changes (as in: no need for an shlibs bump, which could prevent some packages from migrating), those were uploaded to unstable, others went to experimental.
• Some cherry-picked patches were added to libx11, from a stable branch. The 2:1.3.3-4 version has been unblocked for squeeze, and brings support for Compose O A and for Compose \ o /.
• I also reverted the removal of the (famous?) apple:badmap and apple:goodmap options for macintosh keyboards in xkeyboard-configuration (which produces the xkb-data binary package), thanks to a bugreport from Yves-Alexis Perez; it s been unblocked for squeeze as well. If someone notices an inversion of those keys after the upgrade, that s probably because one of those options was added at some point, was ignored and unnoticed, and finally taken into account. Depending on the case, it s sufficient to switch to the other one, or to remove it entirely.
• Many bug submitters were pinged by Julien Viard de Galbert. But another report should appear soon, following TXBW1 and TXBW2.
• More drivers were updated to their latest upstream versions, and uploaded to experimental.
• Thanks to an xserver-xorg-video-mga user (Ferenc W gner), we were able to extract and apply a patch from launchpad s #292214 to fix the dual head breakage. Since we haven t seen any complains since then, we ll probably ask for an unblock for squeeze.

What are the XSF plans?

• Keep close track of upstream work, possibly contributing there. We re mostly up-to-date with the RC1 for X11R7.6 and it d be nice to keep it that way, but that requires time/work.
• Keep on answering new bug reports quickly, before bug reporters vanish or switch to another system (a broken X can trigger this kind of reaction).
• Keep on pinging older bug reports. Anyone is welcome to join and help, there s no high profile required to do so, as confirmed by Julien Viard de Galbert.
• To make it easier, it would be nice to have some documentation written down, instead of relying on everyone s own memory. There s a lot of wiki pages about X in Debian, but they might be outdated, incomplete, or inaccurate. Building up some consistent documentation should help people understand how they can contribute, and how to do so.
• It d be nice to have some documentation targeted at users as well, so refreshing the old XSF FAQ would be welcome, as well as shipping it in some package for offline use.

Another one, just not to forget it, since I'm just starting to play with grsecurity. When building package under pbuilder/cowbuilder and using a grsec kernel, you have some stuff to tune. I built my grsec kernel with the sysctl options enabled, so it's easier to fix. The first thing I needed, not directly related to building packages, is the permission for my user to execute stuff in untrusted folder (since I really need to be able to run stuff from my home). I've configured Trusted Path Execution with:

corsac@hidalgo: sudo sysctl -a grep kernel.grsecurity.tpe
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = 500
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.tpe_restrict_all = 1 So what I need from there is to add my user to that group:

corsac@hidalgo: sudo addgroup --gid 500 grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
corsac@hidalgo: sudo adduser corsac grsec-tpe
Adding user corsac' to group grsec-tpe' ...
Adding user corsac to group grsec-tpe
Done. That works fine for general usage (at the cost of less protection for my user). When trying to build stuff in pbuilder, the first problem I hit was during dependencies installation:

[81903.221359] grsec: From 127.0.0.6: denied chmod +s
of /home/corsac/debian/pbuilder/build/cow.8616/usr/local/share/sgml/stylesheet
by /home/corsac/debian/pbuilder/build/cow.8616/bin/chmod[chmod:10424] uid/euid:0/0 gid/egid:0/0,
parent /home/corsac/debian/pbuilder/build/cow.8616/var/lib/dpkg/info/sgml-base.postinst[sgml-base.posti:10421] uid/euid:0/0 gid/egid:0/0 grsec enforces some more protection when in a chroot, and especially forbids some operations in there. So I add an exception, using sysctl. For that, a convenient /etc/sysctl.conf.d/grsec.conf will help:

# we need to do stuff in chroots for package building
kernel.grsecurity.chroot_deny_chmod=0

# lock grsec sysctl
# kernel.grsecurity.grsec_lock=1 The last one is still in comment since I know I'll have to tune further the sysctl. With this, the build-deps install fine, but when starting the build itself, it fails because I can't execute stuff inside chroot, and especially not debian/rules:

Sep 20 19:43:24 hidalgo kernel: [87339.510137] grsec: From 127.0.0.6: denied untrusted exec of
/home/corsac/debian/pbuilder/build/cow.26657/tmp/buildd/evolution-data-server-2.30.3/debian/rules by
/home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10916] uid/euid:1234/1234 gid/egid:1234/1234,
parent /home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10895] uid/euid:1234/1234 gid/egid:1234/1234 That's again because of TPE. Because, inside the chroot, the pbuilder user (uid 1234) doesn't belong to the grsec-tpe group (which doesn't even exist). So the correct fix here is to create a 500 group inside the chroot, and add the pbuilder user:

corsac@hidalgo: sudo cowbuilder --login --save-after-login
-> Copying COW directory
[ ]
root@hidalgo:/# sudo addgroup --gid 500 grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
root@hidalgo:/# sudo adduser pbuilder grsec-tpe
Adding user pbuilder' to group grsec-tpe' ...
Adding user pbuilder to group grsec-tpe
Done. Et voil !

So I don't forget it, since recent sudo package resets environment even for $HOME, the working sudoers (5) for me is:

Cmnd_Alias PBUILDER = /usr/sbin/pbuilder, /usr/sbin/cowbuilder
Defaults!PBUILDER env_keep+=HOME You may have to adjust the commands, YMMV.

At least that's what it looks like right now. No less than five times did he offer his resignation as prime minister of Belgium to the king. Looks like fifth time is a charm now, too we get to go elect a new parliament in a month or two. Sigh. The 'fun' bit is, there's no real reason why this is necessary. The main issue that they've been talking about these past few years is the 'BHV' thing. While the issue is somewhat complex and, I'm sure, involves a huge heap of all kinds of side issues, the crux of the matter is that there's one group of politicians who wants to forbid another group of politicians from running in a region of the country around the capital. Now I'm sure that's hugely important to politicians after all, their career depends on it but beyond a few fanatics in and around that very capital, I'm pretty sure nobody actually cares what the particular names are of the particular groups of people that appear on the list of people they can vote for. Because, you see, this isn't actually about politicians wanting to forbid other politicians from running; it's about politicians wanting to forbid other political parties from running. Which, of course, makes a whole world of difference. Yeah, right. Now I wouldn't care about this much, except that it interferes with the smooth running of this country. The fact that they've come up with "problem" after "problem" related to this BHV "issue" for these past years has made it hard(er) for the government to actually to any real work. So although I hate the current situation, I'm actually quite relieved that an election is coming up. Perhaps this time we can get the fanaticals out and have a real government. (no comments allowed on this item; please use your own blog)

For some reasons, I had to create some slides, and it's been some time I wanted to do some latex/beamer, so I jumped in and created them using vim (hating latex/beamer a few times in the process, but that's expected. At least, I didn't have to hate OpenOffice this time). Now, when presentation time comes, I started missing the nice Presenter Console extension for OpenOffice. It's a nice extension which (a bit like Keynote) (and maybe other) enables you to seperate the beamer and laptop screens. So you put on the beamer the presentation itself, and on the laptop one you can put you notes, the next slide preview, a nice countdown etc. Really useful, but it's only for OpenOffice (or PowerPoint) slides, not for pdf ones. So I started looking at PDF readers which could do that, and found multiple solutions:

• Cyril (Brulebois) proposed to start two pdf readers (one for each screen), to have them shifted by one slide, and to advance both of them at the same time (using xdotool for example). Not really convenient but, indeed, it /could/ work;
• in the same vein, some people proposed to use Impress!ve, which has the ability to run a script when changing slide. So again, one starts two pdf readers (Impress!ve and another one) and make Impress!ve change the preview reader each time it changes slide. Again, it should work, but it's not really convenient.

So in the end, I was almost ready to submit a bug report to epdfview (which I already maintain in Debian) asking for that new feature, when I found PDF Presenter Console which does exactly what I want. I'm not sure the project is really active at the moment, and I had some problems with the tool not detecting one of the screen (so it only appears on the beamer, or only on the laptop). It might be related to xfwm4 or something, I already contacted the developer about that. In the end, it's not 100% reliable (so I'm not yet packaging it for Debian) (especially since it uses CMAKE) but once it started, it does the job pretty fine. That's just something I wanted to share in case people would be interested.

RCBW - week #10 Here is this week squashes, by yours truly (also truly amazed by the simple fact of having reached the 10th RCBW week, my DDPO NMU section probably hates me now):

• 09/11/2009 bug #545652 - dfsbuild - fix build w/ GHC 6.10 (use OldException)
• 10/11/2009 bug #552668 - kernel-patch-badram - add missing target binary-arch
• 11/11/2009 bug #552666 - liblockfile-ruby - add missing target binary-arch
• 12/11/2009 bug #556034 - libbatteries-ocaml-dev - rebuild against recent sexplib
• 13/11/2009 bug #553011 - sdate - add dh_installdeb to fix lack of ldconfig in postinst
• 14/11/2009 bug #553124 - libapreq2 - move dh_installdeb to fix lack of ldconfig in postinst
• 15/11/2009 bug #540493 - libcgi-application-basic-plugin-bundle-perl - fix file overwrite when upgrading from Lenny

This week I've made (once more) a friday/saturdary rush to keep up, mostly because during the week I've been traveling (again) back to Italy and also because on mon/tue we invited Luk in Paris to discuss some Mancoosi-powered Britney (potential) improvements (and yes, have some fun also. BTW, Yves, Ralf was not visiting, he has been teaching in Paris for quite a while now ). More on this as soon as the advantages will turn potentiality into reality. To conclude ... drum roll ... please join me in cherishing this week new RCBW participant, welcome on board Tim!

Ok, so following the trend, I created some time ago a new GPG key, which I'm now transitioning too. I've set up a transition document, available at http://molly.corsac.net/~corsac/key-transition.txt. It's signed by both the old and the new keys and is reproduced below:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160,SHA512
Wed, 11 Nov 2009 13:44:05 +0100
I've recently set up a new RSA-based GPG key, and will be transitioning away
from my old DSA-based one.  The old key will be revoked soon, so I prefer all
future correspondence to use the new one.  I would also like to ensure that
this new key is well-integrated into the web of trust.  This message is signed
by both keys to certify the transition.
The old DSA key was:
pub   1024D/C5C05BAE 2004-11-11
      Key fingerprint = DE26 2FC4 7097 FFC6 DE2C  D8C0 4D44 C020 C5C0 5BAE
The new RSA key is:
pub   4096R/71EF0BA8 2009-05-06
      Key fingerprint = 4510 DCB5 7ED4 7040 60C6  6476 3055 0F78 71EF 0BA8
If you already know my old key, you can verify that the new key is
signed by the old one:
  gpg --check-sigs 71EF0BA8
If you don't already know my old key, or if you're extra-paranoid, you
can check the fingerprint against the one given above:
  gpg --fingerprint 71EF0BA8
If you have previously signed my old DSA key, and if you're satisfied
that you've got the correct new RSA key, then I'd appreciate it if you
would sign my new key as well:
  caff 71EF0BA8
The caff program is in the signing-party package in Debian.  Please be careful
to generate signatures that don't rely on the weakening SHA-1 hash algorithm,
which requires some careful configuration even if you've already configured
gpg correctly.  See http://www.gag.com/bdale/blog/posts/Strong_Keys.html for
the gory details.
Thanks,
- --
Yves-Alexis Perez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREDAAYFAkr6sqQACgkQTUTAIMXAW64HiACeIyabQueDHAeiAX8EkIeApiDj
++UAn2z7YkjHx0lQh0+s5WdhikG0YztiiQIcBAEBCgAGBQJK+rKkAAoJEDBVD3hx
7wuodUcQAKMbG9Rehxz+uZ6fST99cHt5Fjnv9TorY4hQaQK+85ZgiwPaHMHfYM1G
5hcrXI+JFUpz8j40deZuaWuspOdHBHwnHNQril8MqT0CJgtB6HFTo+w/7Lmmui5M
DDMMed39UJl7bF73hV9ywGecxPpeh+dtoVnh0VT16uK2xTvW6ICEZgaPw1xfPUHS
+jxQ7I05X1OWQkPpmhxXJqGclDyO+qx4CJZsOxUAvt2LphHxhZxB3QE5OUdudGKQ
AH6KhC4rpNQdJVMX20SG8PybL/AipN3Y8N/63VkoqVC2heRlaQ69HjsuqIAkIyan
hHnqmJH8Q+TDTbdKZvOQv6jcd4o3VSibz0T9MwnOfqQ0uRYyTpaXC0vLUH6lXaC4
eK+VVWbY8vCAFHR3h80Q61i2me2HU5ly7a/W22dz19zzDNNC5q9MO78uIYkUK78N
Z0wzJrmOxRyhvs5DOSOpNVlXZhffNQM1f42xxG8cUDaIf7pR5jK+xqHV7tIBQE1D
CrD0mt+YQCnngK0i4wQTO7VT/vjypf4A9W+VSsoJJpRhBbngU4pHu9JWqO84/7AA
j5FN8ug15MWysaS+FQ/EqzHmT7BGBWaTPv3yGlHKUjx0w4bPEpbH7y3fwHAcmOFf
xFRzvZFQ03zeer06yAqTVNuwr77HZgrCzgyQVgIkegAg6iUPiZcs
=CBT+
-----END PGP SIGNATURE-----

Ok so there were some reactions to the Call for help post. I had three direct offers for help in pkg-xfce, not sure if other teams had such propositions. Some people asked me to correct various number for the active contributors . Basically, the numbers are what the feeling I got from people working in those team. Julien Cristau wants me to correct the number of debian-x active contributors to 0. (yes, zero, that means nobody, nadie, personne). Basically he doesn't have time anymore, and Brice Goglin can't really keep up. So, for those who care about shiny X effects, and stuff like that, you help would be gladly appreciated (and no, you don't have to own each and every chipset in the world to give some time). Aurelien Jarno wants me to add that at the moment there are 2 (two) active libc contributors, plus one on GNU/Hurd and one on kfreebsd. Frans Pop wants me to add that there are ~85 people working on d-i and that the problems the team might face aren't only related to the lack of manpower (and I don't really want to enter politics) Finally, it seems that some people (well, only one at the moment, but it's enough for to feel the need to precise) though the numbers previously given would dismiss contributions for the active contributors. That wasn't my intention, so I apologize if you are an active contributor in one of that team and thought I dismissed your contribution. If it wasn't clear enough, my point is to show that quite some teams are lacking manpower (some team miss other things too, like leadership, coordination or whatever) and users shouldn't be scared to contribute to them. Those are core teams, without them Debian wouldn't work at all (not to mention derivatives), so it's a good idea to join them. Now, what if you do want to help, but don't know how. On the previous post I gave links to teams website, wiki page or QA page. You should be able to find a mailing list or contact mail you should be able to write to. Just write that you want to offer some help, that you don't know how and where to start. Add what you're interested in, what you find fun, and your technical knowledge. Don't be shy, and you don't need to be a Debian Developer (nor even a Debian Maintainer) to contribute. Thanks!

So yesterday we had a really nice meeting with few french Debian folks. Luk and Ralf were visiting us, so we went at Prosper's for some meat and wine (and Aberlour). We were a bit too much to be able to speak to everybody (so mainly there were two 6-packs of people), but it was fine anyway. Though, the main point of the evening was that some (most?) teams in Debian are really (*really*) understaffed, and it might become problematic in the near future (like now). For example, from what I understood:

• debian-x has one active contributor
• pkg-xfce has one active contributor
• evolution has one de factor contributor
• pkg-gnome is better since Josselin had some help, but it's still not perfect
• d-i has only one active contributor
• libc has only one active contributor

I don't know the state of other teams, but it doesn't really look fine for the incoming freeze. So if you want to give some help, even if you're not yet technical enough, feel free to offer it to the teams above. Usually, starting with just using the package is enough. If you use it, you want it well-maintained, and there _are_ stuff to do to which don't require large technical knowledge, and the (few) active contributor will be happy to have some help and point you to what you can do. If you want to give some time to Debian, before filing some ITPs (even if you'd really like to have that package you use everyday), check if you can't do something for those above teams (and others which might need help too, like release team or kernel). Oh, and don't be scared, working on Debian is fun. It's time consuming, but it's rewarding. Don't let it become not fun.

Since we uploaded Xfce 4.6 into Debian Sid, last week, not much have happened to most people. We had some bug reports, but mostly from amd64 users, because i386 and ppc packages are not yet available. The aren't all built at the moment. You can follow the build status here if you want. Most packages are built now, but xfce4-settings is waiting for libcanberra which is not installable because of a transition and a package waiting in NEW. It's quite painful to have this upload a bit harmed by this, but there's not much we could do. We already passed NEW when uploading to experimental to minimize the delay where unstable would be unusable, but we can't do that for packages we don't maintain but depend on. I'm wondering if, for Xfce 4.6.1 (which is supposed to be out this weekend but won't because of some problems on the release manager box), I won't disable the sound settings in xfce4-settings and thus get rid of the libcanberra build-dep. If you have keyboard (layout and shortcuts) related bugs, make sure to re-assign the shortcuts correctly, and re-set the keyboard model and layout in the keyboard settings. There was a quite large xorg update at the same time, which now use hal and console-setup stuff. So you may have problems with that and it can be a bit hard to know what's going wrong (settings migrations from Xfce 4.4 to Xfce 4.6, bugs in Xfce 4.6, configuration problems, conflicts, bugs in xorg etc.) But all in all, for amd64 users, it seems the transition is well received and not that bugs have been reported yet (I'm expecting bug reports to come more when i386 users begin upgrading).

Following the ACCEPT on packages on NEW during my vacations and the ack from the release team, I've just uploaded all Xfce 4.6 packages to unstable. Packages for your architectures should arrive on your mirror along the weekend. the NEWS.Debian (which will be displayed if you use apt-listchanges (which is a good idea)) will warn you about some upgrade precautions to take. I'm reproducing it here:

xfce4 (4.6.0.1) unstable; urgency=low

Xfce 4.6 includes multiple changes which are not directly visible to the
user but might cause problems in rare cases.

Settings management have been moved from the old MCS Manager to the xfconf
system. User settings will be migrated automatically at first Xfce 4.6
startup using the /usr/lib/xfce4/xfconf-migration/xfconf-migration-4.6.pl
script contained in xfce4-utils. Once those settings have been migrated,
the automatic run will be disabled but the script will stay (for future
users).

Menus are now managed using a dedicated library, used by various Xfce
components (including xfdesktop4 and the menu panel plugin). This library
tries to support the freedesktop.org specifications, but is not totally
complete and thus lacks the support for some items, like .
This renders useless the menu editor previously shipped with Xfce 4.4.
Solutions for menu editing can be found at the following address:
http://wiki.xfce.org/howto/customize-menu

As the upgrade is pretty invasive, it is recommended to quit Xfce before
doing so, but it's not required and upgrades have been made from the
desktop environment without problems. In that case, be sure to quit Xfce
not long after the upgrade.

-- Yves-Alexis Perez <corsac@debian.org> Thu, 02 Apr 2009 21:19:53 +0200 The xfce4-goodies will be updated soon to match the new goodies present for Xfce 4.6, and the desktop task (the standard install when you choose desktop=xfce in the installer) will be updated too (there's an ongoing discussion on pkg-xfce mailing list to select which packages should be part of that install). Have a good upgrade!

As some people may have noticed (especially people in #debian-xfce and other Xfce fans), Xfce 4.6.0 has just been released. Packages are already prepared, since the packaging is done in parallel with the release cycle. I don't really plan to upload anything to my repository, now that Lenny is released and we can break unstable. That being said, I won't upload to unstable directly, as we have some packages which need to go through NEW. NEW is quite huge this days, so those packages won't leave it soon, and for consistency I'd prefer not breaking unstable completely, with a mix of 4.4 and 4.6. So first uploads targeted at experimental, and then when all packages are out of NEW, unstable. In the meantime, I already uploaded a new desktop-base version with config files useful for the new configuration system in 4.6. One of theses files will conflict with one in xfce4-session. Yeah, I shipped that file in xfce4-session when it was private, now it's time to go official. So yes, this morning you may have a conflict with desktop-base. It's not a problem in desktop-base (you don't need to report a bug). Just an inconsistency with an un-official, un-supported repository package, and an official package from main. Just force the overwrite or something like that. Or hold the upgrade until xfce4-session is available. As I already said, no special dependencies informations will be used in packages uploaded to Debian, so it may break your system at upgrade. The best solution would be to clean the packages from my repository before trying to upgrade to the ones in Debian (but it should not be too broken, in the end). For the record, besides the desktop-base / xfce4-session conflict, I didn't have any problem upgrading to the packages I should upload to experimental. More on this when things have settle down and we start uploading to unstable.

Hey hey, look what I had in my mailbox this morning: Just in time for Lenny release, here are my precious cookies for BugSprint. Thanks Franklin!

Hey, Xfce 4.6 Beta 2 Hopper has just been released and, guess what, packages are already available. Still not in unstable (or even experimental), that will wait post-lenny. You can install it from my repository, and, as usual, there's no Debian support on them. The known_issue page is currently quite empty, and this beta looks really quite polished. Packages currently available are i386 and amd64, powerpc will be available when I have time to put the mac at build. This beta features mostly bug fixing, and some features too:

• power management stuff in xfce4-session. Based on a patch included long ago in Ubuntu, it means that when you click the logout button it'll ask you if you want to suspend/hibernate the box. That works through hal and it may need some tuning on the machine. Reports appreciated here or there. 
• soname bump in xfconf. That means package renaming from libxconf-0-0 to libxfconf-0-2. No standard upgrade path (Replaces:) is provided because I don't want to clutter the packages before upload to Debian. This will continue for following changes (libxfconf-0-3 for rc for example). For the final release the library name will be changed to libxfconf-1 and the soname will be reset to 0, which means the package name will be libxfconf-1-0. There again, no upgrade path will be provided for people using my repository. The only upgraded path supported will be 4.4 →4.6. (but you won't be totally alone in the dark, I use 4.6 beta on my laptop so I'll pass through hell before you)
• keyboard shortcut can be configured (both window manager ones and applications) and there is now conflict handling
• session management has been greatly improved, you can now save the session immediately (a long-wanted feature) and it manages stuff like SMRestartImmediately etc.

The official announcement can be found there.
Have fnu!

The first Xfce beta for 4.6 (codenamed “Fuzzy”) has just been release. As usual, it's available in my private repository, for early testers. As usual, be warned, this is a beta, not supported by Debian in any way. Bugs can and should be reported to Xfce Bugzilla. The known issues wiki page has been updated, please look at it before any test, to see what's supported and what isn't, see the various problems you may encounter etc. Some stuff has changed since Pinkie  so some settings aren't valid anymore. Migration script from 4.4 has been updated,but not for alpha users. I cooked some script to migrate those settings from an alpha:

 #! /bin/sh

for prop in $(xfconf-query -c xfce4-keyboard-shortcuts -l grep -v provider grep -v command )
do
  value=$(xfconf-query -c xfce4-keyboard-shortcuts -p $prop tail -n1)
  newprop="/commands/custom$ prop "
  echo "prop=$ prop , newprop=$ newprop , value=$ value "
  xfconf-query -c xfce4-keyboard-shortcuts -n -p $ newprop -s "$ value " -t string
  xfconf-query -c xfce4-keyboard-shortcuts -r -p $ prop
done Enjoy!